is there any reason this hasn't recieved any attention

should def be merged.

Since this is already an api breaking change,
maybe it would be a good idea to investigate if multiple lua versions can be supported in the future and build the API with that in mind.

I mean the WASM side technically supports that already by simply changing the glue file URL when starting an instance.
But the actual wasmoon code is closely tied to the lua version being used via the submodule.
(one could probably make a compat repo later to polyfill the gaps, or leave it up to the community)

This becomes a necessity down the road, as bytecode between versions is largely incompatible,
and therefore, quick version switching would go a long way to ensure everyone's happy,
as not everyone is at liberty to just upgrade the used lua version.

it also could be a good idea to expose wasmoon's current version in some way,
maybe by exporting the version as variable that rolldown generates.
So that wasmoon consumers can easily adapt to future api changes more dynamically.

Exposing more of the globals that lua defines in luaconf.h like the version ones could also help with all that.

@neico @ceifa I wanted to suggest this, but I don't have a formal strategy. However, I think it's a great resource.

In another project, through C patches, I backport Lua 5.1 to the ABI interface of Lua 5.4. This way, the Lua version is determined at link time, regardless of the headers used by the project. I'm not sure if this is the best approach.

But this allows for multiple interchangeable WASMs with different Lua versions.

https://github.com/gly-engine/core-native-arduino/blob/3dffc1e313b87e589da5b3f748471a238f89d61d/GlyLua51.h#L56-L76